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Description 

Fieid of The invention 

[0001] Thepr s nt invention relates to the saf deliv- 5 
ery of messages between application programs in a 
transaction-oriented data processing networic, such that 
no messages are lost and none are delivered more than 
once. 

Background To The Invention 

[0002] It is Icnown for updates to computer system re- 
sources (such as databases or file resources) to be 
made as a coordinated set of changes to two or more 

resources, such that either all of the changes take effect 
or none of them does. In this way. resources are pre- 
vented from being made inconsistent from each other. 
If one of the set of update operations fails then the others 
must also not take effect. A sequence of associated op- 
erations which transforms a consistent state of a recov- 
erable resource into another consistent state (without 
necessarily presenting consistency at all intermediate 
points) Is known as a "unit of work*. Transaction 
processing is the execution of discrete units of work that 
access and update shared data. Logical points of con- 
sistency at which resource changes are synchronised 
within transaction execution (e.g. at termination) are 
called commit points or syncpoints (see below). An ap- 
plication ends a unit of work by declaring a syncpoint. 
or by the application terminating. The characteristic of 
a transaction being accomplished as a whole or not at 
all is known as "atomicityV 

[0003] Atomicity of a transaction is known to be 
achieved by resource updates made within the transac- 
tion being hekJ in-doubt (uncommitted) until a syncpoint 
is declared at completion of the transaction. That is, the 
resource updates are only made permanent and visible 
to applications other than the one which performed the 
updates on successful completion. If the transaction 
fails to complete successfully, then all changes that 
have been made to resources during the partial execu- 
tion are removed - the transaction is said to rollback (or 
synonymously to backout), the resources being re- 
stored to the consistent state which existed before the 
transaction began. Any party (e.g. an application or re- 
source manager) with an interest in the unit of work can 
cause a rollback when a syncpoint is declared by indi- 
cating unreadiness to commit. 

[0004] A common problem in the provision of failure- 
tolerant data transmission is how to determine what 
stage has been reached in the transfer of messages that 
were in-doubt (i.e. had not been committed) when a fail- 
ure occurred, to ensure that no messages are lost and 
none are sent more than once. Not all transaction sys- 
tems remember the state of in-doubt messages. 
[0005] The commit procedure is known as a "single- 
phase" procedure if only a single resourc manager (the 



system software which controls resources) is responsi- 
ble for coordinating the commitment f changes made 
by the transaction. SingI phase commit processing is 
ffictent in normal forward processing, consisting simply 
of issuance of a COMMIT peration instruction by an 
application or resource manager and then execution of 
the operation by the recipients of the instruction. There 
may be more than one resource manager involved, but 
the coordinator only calls each one once at syncpoint 
time to Instruct them either to commit or rollback. In the 
vast majority of cases, all resource updates will be com- 
mitted without error or interruption. However, if a prob- 
lem arises (e.g. system or communication link failure) 
such that not all resource managers are unable to com- 
mit, then the resources can end up in an inconsistent 
state with some commits having been completed while 
others have not. The inconsistent resources then re- 
spire resynchronisation. The cost of rebuilding non-crit- 
ical resources following such a problem may be tolera- 
ble in view of the efficiency of the single-phase commit 
procedure. 

[0006] In contrast, a two-phase commit procedure is 
often required to protect critical resources from such in- 
consistencies. For example, a financial application to 
carry out a funds transfer from one account to another 
account has two basic operations no perform to critical 
resources: the debit of one account and the credit of the 
other. It is important to ensure that either both or neither 
of these operations take effect. A two-phase commit 
procedure under the control of a syncpoint manager 
consists of the following steps: 

1. During a prepare phase, each participant re- 
source is polled by the syncpoint manager to deter- 
mine whether the resource is ready to confirm and 
finalise all changes. Each resource promises to 
commit the resource update if all resources indicate 
readiness (i.e if they successfully complete the pre- 
pare phase); 

2. During a commit phase, the syncpoint manager 
instructs all resources to finalise the updates or to 
back them out if any resource could not complete . 
the prepare phase successfully. 

[0007] The advantage of the additional prepare phase 
is in reducing the likelihood of inconsistencies, but there 
remains a period during processing at which even two- 
phase commit leaves the possibility of inconsistencies 
between resources if an error occurs. Also, there is a 
cost which accompanies the two-phase commit*s reduc- 
tion in the probability of inconsistencies: since all updat- 
ed resources must be locker to prevent further update 
access for the duration of the unit of work, additional 
steps in the commit processing may represent a consid- 
erable reduction in concurrency of resource update 
processing (partcularly it many resources are involved). 
If the resources are distributed around a network, two 
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phase commit requires a distributed unit of work, which 
introduces the likelihood of looks being held t riongp • 
riods, and also requires much mor c mpllcated recov- 
ery procedur s. Three-phase and other multi-phase 
commit procedur s may be implemented t further re- 
duce the window of time in which a failure can cause 
inconsistencies, but each additional step of preparation 
for commit represents a cost in loss of concurrency 
[0008] The IBM System Network Architecture SNA 
LU6.2 syncpoint architecture (reference SC31-6608 
Chapter 5.2 'Presentation Sen/ices - Sync Point Verbs*, 
published by International Business Machines Corpora- 
tion) has been known to coordinate commits between 
two or more protected resources. This architecture ad* 
dressed syncpoint facilities consisting of a syncpoint 
manager which performed both syncpoint and associat- 
ed recovery processing running in a single applk:ation 
environment. Several applications could run simultane- 
ously in this environment. The LU6.2 architecture sup- 
ports a syncpoint manager (SPM) which is responsible 
for resource coordination, syncpoint logging and recov- 
ery. 

[0009] According to the SNA LU6.2 architecture, in 
phase one and in phase two, commit procedures are 
executed and the syncpoint manager togs the phase in 
the syncpoint log. Also, the syncpoint manager logs an 
identificatton of a logical unit of work which is currently 
being processed. Such logging assists the syncpoint 
manager in resource recovery or resynchronisation in 
the event that a problem arises during the two-phase 
commit procedure (e.g. a problem such as failure of a 
communication path or failure in a resource manager). 
If such a problem arises subsequent to entering the two- 
phase commit procedure, the tog is read and resource 
recovery processing takes place to bring the resources 
involved in the commit to a consistent state. This two 
phase commit procedure requires tocks to be held 
across different computers using distributed units of 
work. 

Summary Of The Inventton 

[001 0] In a first aspect, the present inventton provides 
a method of inter-program communication in a transac- 
tion-oriented data processing network wherein a sender 
program is responsible for sending messages from a 
first node of the network and a receiver program is re- 
sponsible for receiving messages at a second node of 
the network, messages to be transmitted between the 
two nodes being sent from the sender program within a 
first syncpoint-manager-controlled unit of work and be- 
ing received by the receiver program within a second 
syncpoint-manager-controlied unit of work such that the 
sending and receiving operations are held in-doubt (un- 
committed) until resolution of the first and second units 
of work, respectively, characterised in that the first and 
second units of work are logically linked so that commit 
processing at resolution of the units of work comprises 



ither 

in response to successful receipt of the m ssages 
by the receiver program, committing said second 
5 unit of w rk, transmitting to th sender program a 
positive confirmation of receipt, and in response to 
the positive confirmation committing the first unit of 
work; or 

in response to unsuccessful receipt of the messag- 
10 es, rolling back the second unit of work, transmitting 
to the sender program a negative confirmation of 
receipt, and in response to said negative confirma- 
tion backing out the first unit of work. 

IS [0011] The present inventton reduces the problem of 

the known single-phase commit procedures of failures 
during commit processing causing inconsistencies be- 
tween resources that then require resynchronisatton. 
and also avoids the undesirable increased tocking of re- 
sources that is a feature of the extra prepare stage in 
the known two-phase commit procedures. 
[0012] Preferably, if the confimiation from the receiv- 
ing program is lost, due to a system or communicatton 
link failure, then the first unit of work remains in doubt 
Log records which were written for each get and put op- 
eration performed by the sending and receiving pro- 
grams are then examined to determine which opera- 
tions have been committed at the receiving end thereby 
to determine which operations should be committed and 
which should be backed out at the sending end. 
[001 3] The present Inventton may be Implemented in 
a network of computers wherein application programs 
communicate using messaging and queuing and where- 
in a message queue manager program is located at 
each computer in the network, the transmission be- 
tween the aforesaid sender and receiver programs be- 
ing transmission between respective queue manager 
programs. The nodes of the network are either message 
queue managers or computer systems on which one or 
more queue managers are tocated. Message transmis- 
sion between queue managers involves a first queue 
manager getting an applicatton-program-originated 
message from a queue and sending the message, and 
a second queue manager receiving the message and 
putting it onto a second queue (either for processing by 
a local application program, or for transmission to an- 
other queue manager if neither the first nor the second 
queue manager was the destination queue manager). 
Messaging and queuing is described in the document 
'IBM Messaging and Queuing Series • technical refer- 
ence ' (SC33-0850-01. 1993). and betow in relatton to 
an embodiment of the present inventton. 
[0014] It is preferred that each message-sending or 
message-receiving unit of work may include a plurality 
of messages, and that each confirmation of receipt (or 
receipt and storage, if received messages are put to 
queues) may relate to such a plurality of messages. This 
method of transmitting messages in a batch as a unit of 



2S 



30 



35 



40 



45 



SO 



3 



5 



EP 0673 523 B1 



6 



work provides a great improvement in processing effi- 
ciency, since the transport connection direction (f r- 
wards f r m ssage transmission and backwards for 
confirmation of rec ipt) is only turned ar undattheend 
of each batch. This is distinguished from the prtor art 
method of sending messages to queues as individual 
units of work and committing after each send operation, 
whbh risks leaving resources at the sending end rn an 
inconsistent state with resources at the receiving end. 
and requires a change of direction of message flow after 
each send and after each confirmation if two phase com- 
mit is used. This batch transmisskrn of messages be- 
tween sending and receiving programs, as a stage of 
the transfer of messages between application pro- 
grams, is also clearly distinguished from batch process- 
ing by an application program, which is well known in 
the art. 

[001 5] The messages which may be transmitted as a 
batch in this way may be logically unrelated and may be 
destined for different application programs (which may 
be served by different queue managers) - the only com- 
mon factor between the messages which is necessary 
for them to be transmitted as a batch between a first and 
a second queue manager is that the second queue man- 
ager is the next queue manager from the first queue 
manager on the way to each message's destination 
queue manager. Prior art methods of message trans- 
mission do not enable batch transmission (where batch 
size is greater then one) of messages which are des- 
tined for different application programs, and so cannot 
benefit from the processing effrciency provided by the 
present invention. For many database systems, commit 
processing is the expensive stage of the processing in 
terms of computing facilities - in particular, disk access 
is expensive as compared with RAM processing - so im- 
provements to commit processing efficiency are highly 
desirable. 

[0016] Preferably, the batch has a request to commit 
the batch and to confirm receipt transmitted with it to the 
receiving program, so that commit processing is being 
coordinated by the sending end of the communication. 
A message may be transmitted as a plurality of seg- 
ments if it is too large for the transport connection to 
transfer in one go. Where there is segmentation, the re- 
quest for confirmation will be associated with the last 
segment in the batch. On successful receipt of the batch 
of messages at the receiving end the confirm request is 
acted on by committing the receipt and communicating 
a confirmatk>n of the successful receipt. 
[001 7] In a second aspect, the present inventk)n pro- 
vides a method of inter-program communication in a 
transaction-oriented data processing network wherein 
a message to be delivered is sent to a queue from a 
sending application program at a first computer and is 
then asynchronously taken from the queue to be proc- 
essed by a rec iving applicatk>n program, characterised 
in that: 



ach step f sending a message to a queue or tak- 
ing a message from a queue is carried out under 
th control f a message queue manag r program, 
at least one of which is located at each computer in 
5 th network; 

messages to be delivered to a local application pro- 
gram are put on a local queue serviced by the local 
applicatk)n program; whereas 
messages to be delivered to remote application pro- 
10 grams on remote computers are put on local trans- 
mission queues for transmission, respectively for 
each transmission queue, to the next message 
queue manager program on the way to the respec- 
tive destination remote message queue manager 
programs, wherein all messages put on a particular 
transmission queue, which messages may be des- 
tined for different destination message queue man- 
ager programs, are transmissable to said next mes- 
sage queue manager as a batch of messages within 
a syncpoint-manager-controlled unit of work. 

Description of an Embodiment 

[0018] The present inventkxi will now be described in 
more detail with reference to the accompanying draw- 
ings in which: 

Figure 1 is a representation of the data fields nnak- 
ing up a message; 

Figure 2 is a schematic representation of two pro- 
grams communicating with each other using mes- 
saging and queuing; 

Figure 3 is a representation of two adjacent compu- 
ter systems and the interrelationships between the 
system entities involved in message communica- 
tion according to an embodiment of the present in- 
vention; 

Figure 4 is an oven/iew flow diagram of a method 
of message communication between application 
programs according to an embodiment of the 
present invention; 

Figure 5 is a representation of the message flows 
between processes during normal forward process- 
ing in a method of communicatbn between applica- 
tion programs, according to an embodiment of the 
present invention. 

[0019] Message queuing is a message of inter-pro- 
gram communication which albws programs to send 
and receive application-specific data without having a 
direct connection established between them. Before de- 
scribing the detail of a specific implementation of the 
present inventbn in a messaging and queuing network, 
it will be helpful to describe the general methodology of 
inter-program communication using messaging and 
queuing. 

[0020] A message consists of two parts, application 
data 1 and a message descriptor 2 containing control 
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information 3, as shown in Figure 1 . Tbe applicatbn data 
in a message is defined and supplied by the application 
which sends the message. Ther aren constraints on 
the nature of the data in the message (for example, it 
could consist f one r nrtore of bit strings, character 
strings, binary integers, packed decimal integers, float* 
ing point numbers). Applications view the string of bits 
and bytes that make up a message as consisting of a 
sequence of items which each have a particular data 
type and meaning. For example, if the message relates 
to a financial transaction, the first item 4 may be a four- 
byte unsigned binary integer containing an account 
number and the second item 5 may be a twenty-byte 
character string containing a customer name. This data 
is called the application data. 

[Gfb21] In addition to the application data, a message 
has associated with it some ancillary data. This is infor- 
mation that specifies the properties of the message, and 
is used by the message queuing service to decide how 
the message should be processed. Some of this infor- 
mation must be specified by the application. This ancil- 
lary control information is contained in a data structure 
called the message descriptor 2. 
[0022] A message queue Is a named object in which 
messages accumulate and from which they are later re- 
moved. Each queue belongs to one particular queue 
manager, which is responsible for the maintenance of 
that queue. A queue manager can own many queues, 
but each queue must have a name that is unique within 
the queue manager instance that owns the queue. A 
message queue is not merely a stack: when messages 
are added to a queue, they are added at the end, and 
when messages are taken from a queue, they are nor- 
mally removed from the front (although facilities do exist 
for reading messages in other than a FIFO order - for 
example it may be desirable for messages which require 
a reply to be retrieved as a high priority). 
[0023] The physical representation of a message 
queue depends on the environment, but can be a buffer 
or buffers in main storage, a file or files on disk or other 
permanent storage device, or both of these. However, 
the physical management of message queues is entirely 
the responsibility of a queue manager (the system serv- 
ice that provides the message-queuing facilities used by 
applications), and such details are not made apparent 
to the application program. Applications can viewa mes- 
sage queue simply as a 'black box* in which messages 
accumulate. Applications have no access to message 
queues other than through the message queuing calls 
(such as MQGET for taking messages from a queue and 
MQPUT for sending messages to a queue). Applica- 
tions obtain message queuing services by using the 
message-queuing calls to communicate with the queue 
manager that is installed on the same system as the ap- 
plication (i.e the local queue manager). 
[0024] For message queuing services to be available, 
there must be at least one queue manager on a system. 
More than one queue manager may b required, for ex- 



ample, in order to k p devetopment work separat 
from productkxi work. Each different queue manager in- 
stance is known by its name, which must g nerally b 
unk^ue within the network of interconn cted queue man- 
5 agers so that one queu manager can unambiguously 
kientify the target queue nnanager to which any given 
message should be sent. 

p)025] Applications communicate by agreeing to use 
particular named message queues, sending messages 

10 to the specific target queues that the application pro- 
grams have agreed to read from. The location of these 
queues need not be apparent to the applicatbns which 
send the messages; each applicatk>n interacts only with 
its local queue manager, and it is the network of inter- 

is connected queue managers that is responsible for mov- 
ing the messages to the intended queues. Since cross- 
network communicatk)n sessions are established be- 
tween queue managers rather than between indrviduat 
programs, programs are less vulnerable to network faii- 

^ ures than in certain other types of inter-program com- 
munication. If a link between processors fails, it is the 
job of the queue managers to recover from the failure. 
Programs on the effected processors are not brought to 
a halt by such an event, and indeed need not be aware 

2S that it has happened. 

[0026] Figure 2 is a representation of the flow of mes- 
sages between two communicating programs in a mes- 
sage queuing network in the simple example of one-to- 
one communication. The two programs 10.20 send 

30 messages to each other via queues 30.40 under the 
control of respective queue managers 50,60. The first 
program 10 puts messages onto the second program's 
queue 30 without a dedicated logical connection having 
to be established between the programs (this message 

3S flow is represented in Figure 2 by arrows f 1 . f2. f3 and 
f4). The queue managers 50,60 ensure that the mes- 
sages are moved across the network, such that the pro- 
grams themselves are shielded from network variations 
and complexities. This is represented in Figure 2 by net- 

40 work link 70. All of the work involved in maintaining mes- 
sage queues, in handling network failures and restarts, 
and in moving messages around the network, can be 
handled by the queue managers. Program 20 subse- 
quently takes the messages from the queue 30 to proc- 

^ ess them, when it is ready rather than when the sending 
program 1 0 chooses. Any changes made to recoverable 
resources by the transfer cf messages and subsequent 
processing are recorded in recovery logs 80,90 for use 
in the event of a subsequent failure. 

so [0027] As represented in Figure 3. queue managers 
100 may store messages onto a number of different 
queues. If the messages are eventually to be processed 
by local application programs then the queue manager 
stores them on local destination queues 110; and if the 

ss messages are eventually to be processed by a remote 
application, then the qu ue manager stores them in spe- 
cial local queues krK>wn as transmission queues 120. 
Transmission queues containing messages to be s nt 
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to queues belonging to remote queue managers enabi 
the movement of messages to r mote queues to be car- 
ried out in stages between adjacent queue managers. 
This staging of m ssage transmission, which will be de* 
scribed in detail below, is invisible to the application pro- 
grams involved in the communication. There may be a 
plurality of local destination queues and of transmission 
queues controlled by a particular queue manager, as will 
be explained below. 

[0028] The messages on a transmission queue are 
extended by the queue manager to include a transmis- 
sion queue header in addition to the application mes* 
sage (the data being transferred by an application). The 
transmission queue header is an architected descriptor 
containing the name of the destination queue and the 
message descriptor. Messages on destination queues 
include the application data and a message header 
specifying control information. 
[0029] The transport relationship between two queue 
managers is known as a channel. The key elements de* 
fining a channel are the name of a transmission queue, 
information concerning the transport processes or pro- 
grams 130.150 which send or receive messages over 
the channel (these processes, which are part of the 
queue managers, are known as message channel 
agents - hereafter MCAs). and communicatbns protocol 
and target system information for the destination to 
whuh messages on the transmission queue are to be 
sent. The association between a particular channel def- 
inition and the varbus data model entities involved in 
the message communication is represented by broken 
lines in Figure 3. Each named channel is defined in both 
the sending and receiving nodes. The channel name is 
used in the transmissions between the sender and re- 
ceiver processes to identify the channel to the receiver 
or for a receiver to request that messages from a par- 
ticular channel be sent. Channel definition has some in- 
formation which is common for all environments and 
some which depends on the operating system environ- 
ment and underlying communications protocol to be 
used. 

[0030] The communicatk>n of messages between 
queue managers is carried out by MCAs working in pairs 
across specific channels: one sender 1 30 and one re- 
ceiver 150. A pair of MCA processes uses a transport 
connection 170 such as a VTAM APPC session or a 
TCP/IP connection as a transport layer. Message traffic 
in the opposite direction flows between a sender 160 
and a receiver 140 on a different channel, the channels 
being used effectively as unl-directional pipes between 
nodes. There are four types of MCAs: 

Sender - which takes messages from a transmis- 
sion queue and sends them to a Re- 
ceiver or Requester; 

Receiver - which receiv s nnessages and queues 
them; 

Requester - which s nds a single message to cause 



a Sender or S rver to be started re- 
motely; 

Server - which is started by a message from a 
requester, and then b comes a Sender. 

5 

[0031] An MCA 1 30 dequeues messages from trans- 
mission queues and transmits them over the transport 
connection 170. The receiving MCA 150 queues the 
messages to the destinatbn queues 180 named in the 
^0 message header These two units of work, dequeue and 
enqueue, are performed such that any failure at any 
point in the protocol can be detected and rectified so 
that each message is delivered once and once only. In 
the case where the destinatbn queue is nrx>re than one 
IS hop from the original transmissbn queue, the receiving 
MCA will queue the message on another transmisskxi 
queue for the next hop. This provkles a safe store and, 
in the event that the next connectbn is unavailable, the 
necessary asynchronism to allow this first stage of 
20 transmission to still be carried out. The message format 
and the safe movement protocol are transport layer in- 
dependent so that MCAs can support different transport 
protocols on different channels. The protocols used by 
the MCAs are described below. 
2S [0032] A channel may be started in a number of dif- 
ferent ways: 

1. a terminal operator may issue a START CHAN- 
NEL command; 
90 2. the channel can be triggered, a Sender MCA be- 
ing started automatically by a queue manager when 
a message arrives on the transmissbn queue; or 
3. by a network request - the communications trans- 
port being configured to automatically start an MCA 
3S when a request from the network is received. Re- 
ceiver, Sender and Sender channels could be con- 
figured this way. 

[0033] Before any messages or data can flow down a 

40 channel, the two MCAs which are to use it must first ne- 
gotiate the way in which they are going to communicate. 
Thus, channel initialisation involves negotiation of cer- 
tain protocol parameters, such as which communicatk>n 
partner is going to do any needed conversion of control 

4S and message header data. Two MCAs may be running 
on systems using two different data formats. For exam- 
ple, one may be using ASCII and the other EBCDIC. 
One may be encoding numbers left to right, the other 
right to left. The control information and message head- 

so er data must be converted from the sender's represen- 
tation to the receiver's. Data conversion over channels 
applies only, to control information (such as destination 
queue name, control field Lengths, and the like): no ap- 
plication data conversion is performed by MCAs, since 

ss MCAs do not need to interact with the application data 
in a message when they transmit it. 
[0034] The method of delivering messages between 
applications on different comput rsyst msinvotv sthe 
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following steps, described with reference to Figures 4 
and 5: 

[0035] An application sends a message to a target 
destination queue for processing by another application 
by Issuing (200) an MQPUT connnnand. The local queue 
manager reads the destination queue name specified 
by the application in the message's header and deter- 
mines (210) where to put the message. If the destination 
queue is a local queue then the local queue manager 
puts (220) the message into that local queue. The unit 
of work including the operation of putting the message 
to a queue must be committed before the message is 
available to other applications. An application sen/ing 
that local queue can then asynchronously issue 
MCXsET (230) to take the message from the queue for 
processing. The MQPUT and MQGET operatk>ns are 
within two separate units of work. 
[0036] If the destination queue is not the responsibility 
of the local queue manager, then the k)cal queue man- 
ager puts the message onto a k>ca\ transmission queue 
(240), for transfer to another queue manager. There 
may be a plurality of transmissk>n queues defined for 
each queue manager, but a one-to-one correspondence 
between transmission queues and remote destination 
queues is not necessary. All messages that are to be 
passed between two adjacent queue managers (that is. 
all messages to be sent from a first queue manager 
which have a common nearest neighbour queue man- 
ager in the direction of their respective target destination 
queue managers) can be put in the same transmission 
queue. It is equally possible to have a number of trans- 
mission queues for traffic going to the same next node. 
A maximum batch size is specified (for example 50 mes- 
sages) to limit the nunnber of messages which will have 
to be resent in the event of a failure. The unit of work 
300 which puts the message to the transmission queue 
must be committed before the message is available to 
other processes. 

[0037] The local queue manager (or an end user) 
starts a sender MCA to transmit messages to the next 
queue manager. The sender MCA then gets messages 
(250) (issues MQGET) from a transmission queue 
owned by this queue manager and transmits them as a 
batch to the next queue manager on the way to the des- 
tination queue manager or queue managers. Each mes- 
sage is either transmitted in one transmission or as a 
plurality of transmission segments in a plurality of trans- 
missions if the messages are too large for the transport 
connection to send in one go (e.g. a message might be 
4 Megabytes in size and the maximum transfer size 32 
kilobytes). The steps of getting and transmitting mes- 
sages is performed within a syncpoint-manager-control- 
led unit of work 330, which is held in-doubt by the sender 
at this stage. Log records are written specifying the in- 
doubt state of the resource updates. The batch has a 
request for confirmatkxi of rec ipt of the batch attached 
to It: this is implemented by the last message (or the last 
transmission segment of the last message) of the batch 



having a Request^Confirm control flag set in its trans- 
misskxi segment header. 

[0038] Each message has a m ssage sequenc 

number associated with it * on of a nrtonotontcally in- 
s creasing sequence of numbers, uniquely assigned t a 
single application message on a channel. Message se- 
quence numbers are used to resynchronise between 
sender and receiver in the event of a link failure or pro- 
gram failure. The highest message sequence number 
10 in the batch is taken as the logical unit of work identifier 
(LUWID) - a unique value defining a batch of messages 
on a channel which are under control of a syncpoint 
manager. 

[0039] The receiver MCA receives (260) the messag- 
IS es and the receiver queue manager determines (210) 
where each message is to be sent (as the sending 
queue manager program did previously). The receiver 
queue manager puts the messages (using MQPliT) 
within a syncpoint-manager-oontrolled unit of work 360 
to queues belonging to the receiving computer system's 
queue nnanager, which may be the actual application- 
specified destination queue for a particular message or 
may be a related transmission queue for the next hop 
towards the target system. 

[0040] Either all of the messages in the batch of mes- 
sages transferred by MCAs are successfully received 
and queued by the receiving queue manager or the 
batch is rejected as a whole and not safe stored at the 
receiver (the unit of work is rolled back). If the batch is 
successfully received and queued then the receiver 
sends an acknowledgement of receipt and storage (a 
Status segment indicating 'No error* is transmitted), 
having logged the LUWID and committed the batch of 
messages together as an atomic action. On receipt of 
the positive acknowledgement the sender also commits 
the batch of messages using the LUWID. this commit of 
the MQGET operation deleting the messages from the 
transmission queue. The next batch can then be started. 
If no messages are left on the transmission queue (and 
a preset time interval has expired) or a request to close 
the channel has been received, then the connection can 
be terminated. 

[0041] If the batch is rejected, an acknowledgement 
of rejectbn (a Status segment indicating Error - which 
nnay include details of the error) Is transmitted to the 
sender which then rolls back its in-doubt messages onto 
the transmissk)n queue ready for retry, and terminates 
the channel. If a batch of messages is roiled back, the 
sequence number or LUWID must also be rolled back, 
to the value of the last successfully committed batch. If 
no confirmation is received, due to transport or commu- 
nication-partner failure, then the channel is terminated 
by the sender and the receiver MCA's unit of work is 
rolled back. If the sender has not yet sent a confirm re- 
quest then the sender MCA should also roil back. If it 
has sent a confirm request then its log records and those 
of the receiver program must be examined to determine 
whether it should be committed or rolled back. The 
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MCAs automatically perform the detemnination of 
whether the first unit of work should be committed or 
rolled back (unless contact cannot be reestablished in 
which cas the operator may take the decision), Foltow- 
ing a r llback. th sending MCA may try t re-establish 
a channel and resynchronise with the sending MCA in 
order to resend the failed batch. 
[0042] Channel resynchronisation is achieved during 
channel initialisatkxi. The sender MCA retrieves from its 
log the in<k>ubt LUWID. or message sequence number 
of the last message sent for which a confirmation was 
also sent. The receiving MCA will check his logged LU- 
WIDs or sequence numbers to determine whether he Is 
In sync with the sender. As a result of the comparison, 
he will confirm or reject the resynchronisatkxt request 
bV returning an appropriate Status segment, containing 
the LUWID or sequence number of the last successfully 
committed message or batch of messages at his end. If 
this value matches the sender's, the sender may commit 
the previously sent messages, and commence sending 
the next one. If the receiver's value matches the previ- 
ous LUWID or sequence number, the sender rolls back 
and resends the prevtous message or batch. 
[0043] The MCAs thus use a syncpoint manager to 
control each batch as a logical unit of work. The unit of 
work including the MQGET of the sender message 
queue manager and the unit of work including the 
MQPUT of the receiver message queue manager are 
logically linked in that both are held In doubt until the 
receiver is ready to commit, messages being committed 
at the receiving end before deleting them at the sending 
end using a single>phase commit protocol. Two phase 
commit is not required as the sender acts as a commit 
coordinator. Any system failure that occurs before the 
end of the batch, either at the sender or receiver, may 
require the unit of work to be backed out during a resyn- 
chronisation phase. 

[0044] This single-phase commit using logical linkage 
of units cf work on different systems avoids the problem 
of a two phase commit needing to synchronise (lock) all 
participating resources in a distributed unit of work. In 
the present invention, resource managers do not actu- 
ally have to synchronise with each other. A limited period 
of inconsistency between resources as viewed by appli- 
cations is accepted, but final consistency is assured 
since atomic transactkan processing is assured. 
[0045] To complete the assured delivery of messag- 
es, the target application which sen/ices the destination 
queue can issue MQGET to get messages from the 
queue as part of a unit of work 390 under the control of 
its local syncpoint manager, to allow rollback of the mes- 
sage to the queue in case of applicatk>n failure or com- 
mit of a successfully processed message to delete it. 



Claims 

1. A method of inter-program communication in a 



transaction-oriented data processing network 
wherein a sender program is responsible for send- 
ing messages from a first node fthen tworkand 
a r ceiver program is responsible for receiving mes- 

5 sages at a second node of the network, messages 
to be transmitted between the two nodes being sent 
by the sender program within a first syncpoint-man* 
ager-controlled unit of work and being received by 
the receiver program within a second syncpoint- 

10 manager-controlled unit of work such that the send- 
ing and receiving operations are heki in-doubt, i.e. 
uncommitted, until resolution of the first and second 
units of work, respectively, characterised in that the 
first and second units of wori( are logically linked so 
that commit processing at resolution of the units of 
work comprises either 

in response to successful receipt of the mes- 
sages by the receiver program, committing sakf 
20 second unit of work, transmitting to the sender 

program a positive confirmation of receipt, and 
in response to the positive confirmation com- 
mitting the first unit of work; or 

2S in response to unsuccessful receipt of the mes- 

sages, rolling back the second unit of work, 
transmitting to the sender program a negative 
confirmation of receipt, and in response to said 
negative confirmation backing out the first unit 
30 of work. 

2. A method according to claim 1 wherein said sender 
and receiver programs are located on adjacent 
nodes within a network, and wherein messages. 

3S which may be destined for different desttnatbn 
nodes, are transmitted between adjacent nodes on 
the way to their respective destination nodes as a 
batch of messages within a unit of woric, the units 
of work incorporating said sending and receiving 

^0 operations being held in-doubt until the end of the 
batch. 

3. A method according to claim 2 wherein the last mes- 
sage in a batch is transmitted together with a re- 

^ quest for commitment of and for confirmatbn of re- 
ceipt of the batch, the commitment of said second 
unit of work and the transmission of said positive or 
negative confirmatksn being in response to said re- 
quest. 

so 

4. A method according to any one of claims 1 to 3 
wherein log records are written to record the in- 
doubt status of said units of work for use in recovery 
processing following a failure during the processing 

ss of said units of work, the log records being read dur- 
ing recovery processing to determine which units of 
work should be committed and which should be 
backed out. 
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5. A methcxj of inter-program communication accord- 
ing to any one of the preceding claims, which im- 
plements messaging and queuing for communica* 
tion b tween application programs, the application 
progranfis sending messages to messag queues s 
from where receiver application programs can 
asynchronously take the messages for processing 

or forwarding on. 

6. A method according to claim 5. wherein communi- io 
cation between application programs running on 
different computer systems of the network compris- 
es at least the following steps: 

a first applicatbn program issuing a put mes- is 
sage instruction under control of a synchpoint 
manager in the sending computer system, for 
sending a message to a message queue; 



whk:h messages may be destined for different 
destination message queue manager pro- 
grams, are transmissible to said next m ssag 
queue manager as one or nr^ore batches of 
messages within syncp int-manager-control- 
led units of work. 

8. A data processing system including a messaging 
manager for Inter-program communication across 
a network of data processing systems, the messag- 
ing manager including sender and receiver pro- 
grams for transferring messages between adjacent 
messaging managers in the network in accordar^e 
with the following transfer protocol: 

a sender program of a first messaging manager 
sending one or more messages within a first 
syncpointHmanager-controlled unit of work; 



sender and receiver transmissk>n programs ^ 
transferring messages between the computer 
systems, as two bgicaify linked units of work, 
using synchpoint managers in both the sending 
and receiving computer systems; and 

a second application program issuing a get 
message instruction under control of a synch- 
point manager in the receiving computer sys- 
tem, for taking the message from the queue; 

30 

wherein the units of work of put message: trans- 
fer and get message are each held In-doubt un- 
til resolution of the respective unit of work. 

7. A method according to claim 1 . wherein a message 3S 
to be delivered is sent to a queue from a sending 
application program at a first computer and is then 
asynchronously taken from the queue to be proc- 
essed by a receiving application program, charac- 
terised in that: 40 

each step of sending a message to a Queue or 
taking a message from a queue Is carried out 
under the control of a message queue manager 
program, located at a computer In the network; ^ 



a receiver program in a second messaging 
manager receiving sakj messages within a sec- 
ond syncpoint-manager-controlled unit of work; 

the sending and receiving operations being 
hekl in-doub. i.e. uncommitted, until resolution 
of the first and second units of work, respec- 
tively; and 

characterized in that the first and second units of 
work being logically linked so that commit process- 
ing at resolution of the first and second units of work 

comprises either 

(i) in response to successful receipt of the mes- 
sages by the receiver program, committing said 
second unit of work, transmitting to the sender 
program a positive confirmation of receipt, and 
in response to the positive confirmation com- 
mitting the first unit of work; or 

(ii) in response to unsuccessful receipt of the 
messages, rolling back the second unit of work, 
transmitting to the sender program a negative 
confirmation of receipt, and in response to said 
negative confirmation backing out the first unit 
of work. 



messages to be delivered to a local applcation 
program are put on a local queue serviced by 
the local application program; whereas 

so 

messages to be delivered to remote application 
programs on remote computers are put on local 
transmission queues for transmission, respec- 
tively for each transmission queue, to the next 
message queue manager program on the way ss 
to the resp ctive destination remote message 
queue manager programs, wherein all m ssag- 
es put on a particular transmission queue, 



9. A data processing system according to claim 6, 
wherein the messaging manager is adapted for 
message queuing inter-program communicatbn 
across a heterogeneous network of data process- 
ing systems, the messaging manager including an 
application programming interface by whk:h appli- 
cations attach to the messaging manager and pro- 
viding queuing services enabling application pro- 
grams to put messages onto message queues for 
asynchronous retrieval by other application pro- 
grams. 
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Patentanspruehe 

1. Ein Verfahren der Interprogramm-Kommunikation 
in einem transaktionsorientierten Datenverarbei- 
tungsnetzwerk, w bei ein Senderprogramm verant- 
wortlich ist, Nachrichten von einem ersten Knoten 
des Netzwerks zu senden. und ein Empfangerpro- 
gramm verantwortlich ist. Nachrichten in einem 
zweiten Knoten des Netzwerks zu empfangen. 
Nachrichten zwischen den beiden Knoten zu Qber- 
tragen. die von dem Senderprogramm innerhalb ei- 
ner ersten, vom Synchronisierungspunkt-Manager 
gesteuerten Ariaeitseinheit gesendet und von dem 
Empfangerprogramm innerhalb einer zweiten. vom 
Synchronisierungspunkt-Manager gesteuerten Ar- 

* beitseinheit empfangen wurden, so da3 die Sende- 
und Empfangsoperationen bis zurAuflosung der er- 
sten bzw. der zweiten Arbeitseinheit in Zweifel ge- 
zogen werden, d.h. nicht festgeschrieben werden, 
dadurch gekennzeichnet. daB die ersten und zwei- 
ten Arbeitseinheiten logisch verknupft sind, so daO 
die Festschreibverarbeitung in der Auftosung der 
Arbeitseinheiten entweder enthatt: 

als Reaktion auf den erfolgreichen Empfang 
der Nachrichten von dem Empfangerpro- 
gramm, die zweite Arbeitseinheit festzuschrei- 
ben, an das Senderprogramm eine positive 
Empfangsbestatigung zu senden, und als Re- 
aktion auf die positive Bestatigung die erste Ar- 
beitseinheit festzuschreiben; oder um 

als Reaktion auf den nicht erfolgreichen Emp- 
fang der Nachrichten. die zweite Arbeitseinheit 
zu wiederholen, dem Senderprogramm eine 
negative Empfangsbestatigung zu senden, und 
als Reaktbn auf die negative Bestatigung. die 
erste Arbeitseinheit zurOckzusetzen. 

2. Ein Verfahren gemaB Anspruch 1. wobei die Sen- 
der- und Empfangerprogramme in benachbarten 
Knoten in einem Netzwerk untergebracht sind, und 
wobei Nachrichten, die fur verschiedene Zielknoten 
bestimmt sein konnen, zwischen den benachbarten 
Knoten uber ihre jeweiligen Zielknoten als ein Sta- 
pel von Nachrichten innerhalb einer Arbeitseinheit 
Qbertragen werden. wobei die Arbeitseinheiten. 
welche die Sende- und Empfangsoperationen ent- 
halten, bis zum Ende des Stapels in Zweifel gezo- 
gen werden. 

3. Ein Verfahren gema3 Anspruch 2. wobei die letzte 
Nachricht in einem Stapel zusammen mit einer An- 
forderung ubertragen wird. den Empfang des Sta- 
pels festzuschreiben und zu bestatigen, wobei das 
Festschreiben der zweiten Arbeits inheit und die 
Obertragung der positiven und negativen Bestati- 
gung eine Reaktion auf dl se Anforderung ist. 



4. Ein Verfahren gema3 einem der Anspruche 1 bis 3, 
wobei die Protokoltautzeichnungen geschrieben 
werden. um den zw ifelhaft n Status der Arbeits- 
einheiten aufzuzeichnen, um diese fOr die Wied r- 

s hersteliungsv rarbeitung im AnschluO an einen 
Ausfall wahrend der Verarbeitung der Arbeitsein- 
heiten zu benutzen, wobei die Protokoliaufzeich- 
nungen wahrend der Wiederherstetiungsverarbei- 
tung gelesen werden, um zu bestimmen, welche Ar- 
beitseinheiten festgeschrieben und wek:he zuruck- 
gesetzt werden sollten. 

5. Ein Verfahren der Interprogramm-Kommunikation 
gemaO einemder vorhergehenden AnsprQche, wel- 
che die Nachrk:htenersteltung und die Warte- 
schlangenbildung zur Kommunikation zwischen 
den Anwendungsprogrammen implementieren, 
wobei die Anwendungsprogramme Nachrichten an 
Nachrichten-Warteschlangen senden. aus denen 
die Empfangeranwendungsprogramme Nachrich- 
ten asynchron herausnehmen konnen, um diese zu 
verarbeiten oder zu senden. 

6. Ein Verfahren gemaB Anspruch 5. wobei die Kom- 
munikation zwischen den Anwendungsprogram- 
men, die in verschiedenen Computersystemen des 
Netzwerks laufen. wenigstens die folgenden Schrit- 
te enthalt: 

ein erstes Anwendungsprogramm, das einen 
Put-Nachrichtenbefehl unter der Kontrolle ei- 
nes SynchronisierungspunktManagers in das 
sendende Computersystem eingibt, um eine 
Nachrk:ht an eine Nachrichten-Warteschlange 
zu senden; 

Sender- und Empfangerubertragungsprogram- 
me, die Nachrichten zwischen den Computer- 
systemen wie zwei logisch verknupfte Arbeits- 
einheiten mittels Synchronisierungspunkt-Ma- 
nagem sowohl an die sendenden ats auch die 
empfangenden Computersysteme ubertragen; 
und 

ein zweites Anwendungsprogramm. das einen 
Get-Nachrichtenbefehl unter der Steuerung ei- 
nes Synchronisierungspunkt-Managers an das 
empfangende Computersystem ausgibt. um 
die Nachricht aus der Warteschlange zu neh- 
men; 

wobei die Arbeitseinheiten der Put-Nachricht, 
der Transfer- und Get-Nachricht jeweils bis zur 
Auflosung der jeweiligen Arbeitseinheit ange- 
zweifelt werden. 

7. Ein Verfahren gemaB Anspruch 1 , wob i eine aus- 
zuhandtgende Nachricht von einem sendenden An- 
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wendungsprogramm in einem ersten Computer an 
eine Warteschlange g send t wird und dann asyn- 
chron von einem Empfangsanwendungsprogramm 
ausderzuv rarb itenden Warteschlange heraus- 
genommen wird, wobei das Verfahren dadurch g - 
kennzeichnet ist, daO 

jeder Schritt, um eine Nachricht an eine Warte- 
schlange zu senden oder um eine Nachricht 
aus einer Warteschlange herauszunehmen. 
unter der Kontrolle eines Nachrichten-Warte- 
schlangen-Managerprogramms erfoigt, das in 
einem Computer im Netzwerk vorhanden ist; 

Nachrichten. die an ein lokales Anwendungs- 
programm zu iiefern sind, in eine k>kaie Warte- 
schlange gelegt warden, die von dem toKalen 
Anwendungsprogramm bedient wird; wahrend 

Nachrichten. die an Femanwendungsprogram- 

me in entfernt stehenden Computem zu liefem 
sind. in bkaie Ubertragungswarteschlangen fur 
die Ubertragung geiegt werden bzw. fOr jede 
Ubertragungswarteschlange an das nachste 
Nachrichten-W^rteschtangen-Managerpro- 
gramm Ober das jeweilige entfemt stehende 
Ziel-Nachrichten-Warteschlangen-Manager- 
programm, wobei alle Nachrichten. die in eine 
bestimmte Ubertragungswarteschlange geiegt 
werden, deren Nachrichten fOr verschiedene 
Ziel-Nachrichten-Warteschlangen*Manager- 
programme bestimmt sind. an das nachste 
Nachrichten-Warteschlangen-Managerpro- 
gramm als ein Stapel Nachrichten in einer von 
einem Synchronisierungspunkt-Manager ge- 
steuerten Arbeitseinheit ubertragbar sind. 

Ein Datenverarbeitungssystem. das einen Nach- 
richtenerstetlungsmanager zur Interprogramm- 
Kommunikatk>n innerhalb eines Netzwerks mit Da- 
tenverarbeltungssystemen hat, wobei der Nach- 
richtenerstellungsmanager Sender- und Empfan- 
gerprogramme enthalt, um Nachrichten zwischen 
benachbarten Nachrichtenerstellungsmanagern in- 
nerhalb des Netzwerks gemaQ dem folgenden 
Obertragungsprotokoll zu ubertragen: 

ein Senderprogramm mit einem ersten Nach- 
rk:htenerstellungsmanager, der eine oder meh- 
rere Nachrichten innerhalb einer ersten, von ei- 
nem Synchronisierungspunkt-Manager ge- 
steuerten Arbeitseinheit sendet; 

ein Empfangerprogramm in einem zwelten 
Nachrichtenersteilungsnnanager, der Nachrich- 
ten innerhalb iner zweiten. v n einem Syn- 
chronisierungspunkt-Manager gesteuerten Ar- 
beitseinheit empfangt; 



wobei die Sende- und Empfangsoperationen 
bis zur Aufiosung der ersten bzw. der zwelten 
Arbeitseinheit angezweif It werden. d.h. nicht 
testgeschrieben werden; und 

5 

dadurch gekennzeichnet, da(3 die ersten und zwei- 
ten Arbeitseinheiten k)gi$ch verknupft sind. so daB 
die Festschreibverarbeitung in der Aufiosung der 
Arbeitseinheiten entweder enthalt: 

10 

(I) als Reaktk)n aut den erfolgreichen Empfang 
der Nachrichten von dem Empfangerpro- 
gramm. die zweite Arbeitseinheit festzuschrei- 
ben. an das Senderprogramm eine positive 
IS Empfangsbestatigung zu senden. und als Re- 

aktion auf die positive Bestatigung die erste Ar- 
beitseinheit festzuschreiben; oder um 

(ii) als Reaktion auf den nicht erfolgreichen 
^ Empfang der Nachrichten. die zweite Arbeits- 

einheit zu wiederholen. dem Senderprogramm 
eine negative Empfangsbestatigung zu sen- 
den, und als Reaktion auf die negative Besta- 
tigung, die erste Arbeitseinheit zuruckzuset- 
2S zen. 

9. Ein Datenverarbeitungssystem gemaO Anspruch 8, 
wobei der Nachrichtenerstellungsmanager ange- 
paBt ist, um Nachrichten in der Interprogramm- 

30 Kommunikation innerhalb eines heterogenen Netz- 
werks von Datenverarbeitungssystemen in Warte- 
schlangen einzureihen, und der Nachrichtenerstel- 
lungsmanager eine Anwendungsprogrammschnitt- 
stelle enthalt, uber die Anwendungen mit dem 

3S Nachrichtenerstellungsmanager verbunden wer- 
den und Warteschtangenbildungs-Services bereit- 
gestellt werden. mit denen Anwendungsprogram- 
me Nachrichten in Nachrichten-Warteschlangen 
zwecks asynchronem Abruf durch andere Anwen- 

40 dungsprogramme legen konnen. 



Revendleations 

4S 1. Proc^d^ de communications entre des program- 
mes dans un r^seau de traitement de donndes 
orients transactbns dans lequet un programme 
6metteur est responsable de remission de messa- 
ges d partir d'un premier noeud du rdseau et un pro- 

so gramme rdcepteur est responsable de ta r^eption 
des messages au niveau d'un second noeud du rd- 
seau, les messages devant 6tre transmis entre les 
deux noeuds 6tant dmis par le programme ^metteur 
k I'intdrieur d'une premiere unitd de tSche comman- 

ss d^e par un gestionnaire de point de synchronisatkxi 
et 6tant re^us par le programme rdcepteur d I'intd- 
rieur d'une seconde unitd de tdche commandde par 
un gestionnaire de point de synchronisation de sor- 
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te que les operations d'dmission et de r^eption 
soient maintenues dans ('incertitude, c'est-d-dtre 
non ngagdes. jusqu'd la resolution des premiere 
et seconde unites de tdche. r spectivement, carac- 
tdrisd en ce que les pr ml^r et seconde unites de 
tSche sont lides logiquement de sorte que Penga- 
gement du traitement d la resolution des unites de 
tdche comprend soit : 

en rdponse ^ la reception correcte des messa- 
ges par le programme rdcepteur. I'engagement 
de tadite seconde unite de tdche, la transmis- 
sion vers le programme dmetteur d'une confir- 
mation de reception positive, et en rdponse k 
la confirmation positive i'engagement de la pre- 
miere unite de tdche, ou 

en reponse d une reception incorrecte des 
messages, le renvoi de la seconde unite de td- 
Che. en transmettant au prograrnme emetteur 
une confirmation de reception negative, et en 
reponse ^ la confirmation negative la restitution 
de la premiere unite de tdcha 

2. Precede selon la revendication 1. dans lequel les- 
dits programmes emetteur et recepteur sont locali- 
ses sur des noeuds adjacents k I'interieur d'un re- 
seau, et dans lequel des messages, qui peuvent 
etre destines k difterents noeuds de destination, 
sont transmis entre des noeuds adjacents en route 
vers leurs noeuds de destination respectifs sous 
forme d'un lot de messages d I'interieur d'une unite 
de tSche, les unites de tSche incorporant lesdttes 
operations d'emission et de reception qui sont 
maintenues dans I'incertitude jusqu'd la fin du lot. 

3. Precede selon la revendication 2, dans lequel le 
demier message d'un lot est transmis en meme* 
temps qu'une demande d'engagement et pour con- 
firmatbn de la reception du tot, I'engagement de la- 
dite seconde unite de tSche et la transmission de 
ladite confirmation positive ou negative se faisant 
en reponse k ladite demande. 

4. Precede selon I'une quelconque des revendications 
1^3, dans lequel des enregtstrements de journali- 
sation sont ecrits pour enregistrer la situation d'in- 
certitude desdites unites de tdche en vue d'une uti- 
lisation dans le traitement de recuperation qui suit 
une defaillance durant le traitement desdites unites 
de tdche» les enreglstrements de journalisation 
etant lus pendant le traitement de recuperation afin 
de determiner quelies unites de tSche devraient 
etre engagees et lesquelles devraient etre resti- 
tuees. 

5. Precede de communications entre des program- 
mes selon Tune qu Iconque des revendications 



precedentes. qui met en oeuvre une messagerie t 
une mise en file d'attente des communications entre 
des programm s d'appiicatien, les programmes 
d'application emettant d s messages vers des fit s 
s d'attente de m ssages k partir desquettes des pro- 
grammes d'application du recepteur peuvent prete- 
ver les messages de fagon asynchrone en vue d'un 
traitement ou pour les propager 

10 6. Precede selon la revendication 5. dans lequel les 
communications entre les programmes d'applica- 
tion s'executant sur des systemes informatiques dif- 
terents du reseau comprennent au moins les etapes 
suivantes : 

15 

un premier programme d'application qui emet 
une instruction de placement de message sous 
la commande d'un gestiennaire de point de 
synchronisation dans les systemes informati- 
20 ques emetteurs. en vue d'emettre un message 

vers une file d'attente de messages. 



des programmes de transmission de cemetteur 
et du recepteur qui transferent des messages 
2S entre les systemes informatiques, sous forme 

de deux unites de tSche liees logiquement. en 
utitisant des gestionnaires de points de syn- 
chronisation dans les deux systemes informa- 
tiques d'emission et de reception, et 

30 

un second programme d'application qui emet 
une instruction de prise de message sous ta 
commande d'un gestionnaire de point de syn- 
chronisatbn dans le systeme informatique de 
3S reception, afin de preiever le message de la file 

d'attente. 

dans tequel les unites de tache des instructions 
de placement de message, de transfert et de 
40 prise de message sont chacune maintenues 

dans I'incertitude jusqu'd la resolution de I'unite 
de tSche respective. 

7. Precede selon la revendication 1. dans tequel un 
4S message devant etre detivre est emis vers une file 
d'attente h partir d'un programme d'application 
emetteur au niveau d'un premier ordinateur et est 
ensuite preieve de fa^on asynchrone de la tile d'at- 
tente devant etre traitee par un programme d'appti- 
so cation de reception, caracterlse en ce que : 

chaque etape consistent e envoyer un messa- 
ge vers une file d'attente ou k preiever un mes- 
sage d'une file d'attente est executee sous la 
ss commande d'un programme de gestionnaire de 

file d'attente de messages, localise au niveau 
d'un ordinateur du reseau, 
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24 



les m ssages devant dtre ddlrvr^s k un pro- 
gramme d'application local sont places sur une 
file d'attent locale desservie par le programme 
d'application local, alors que 

5 

des messages devant dtre d^livrds k des pro- 
grammes d'application distants sur des ordina- 
teurs k distance sont places sur des files d'at- 
tente de transmission locales en vue d*une 
transmission, respectivement pour chaque file io 
tfattente de transmission, vers le programme 
de gestionnaire de file d'attente de messages 
suivant sur I'itlndraire vers les programmes de 
gestionnaire de file d'attente de messages dis- 
tants de destination respectifs» dans lequel is 
tous les messages places sur une file d'attente 
de transmission particuli^re, lesquels messa- 
ges peuvent dtre destines h des programmes 
de gestionnaires de file d'attente de messages 
de destination diffdrents, peuvent dtre transmis 
audit gestionnaire de file d'attente de messa- 
ges suivant sous forme d'un ou plusieurs tots 
de messages k I'int^rieur d'unitds de tSche 
commandoes par un gestionnaire de point de 
synchronisation. ^5 

Systeme de traitement de donnOes comprenant un 
gestionnaire de messagerie destine k des commu- 
nications entre les programmes sur un rdseau de 
systOmes de traitement de donnOes. le gestionnaire 30 
de messagerie comprenant des programmes 6met- 
teurs et rteepteurs destines k transferer des mes* 
sages entre des gestionnaires de messageries ad- 
jacents du reseau conformdment au protocole de 
transfert suivant : 35 



(i) en rOponse k la rteeption correcte des mes- 
sages par I programme r6cepteur. Tengage- 
ment de ladite seconde unite de tdche, en 
transm ttant au programme dmett ur une con- 
firmation de reception positive, t en engageant 
en rdponse k la confirmation positive la premie- 
re unite de tdche. ou 

(it) en reponse k la reception incorrecte des 
messages, le renvoi en retour de la seconde 
unite de tdche. en transmettant au programme 
emetteur une confirmation de reception nega- 
tive, et en restituant en reponse k ladite confir- 
mation negative la premiere unite de tSche. 

9. Systeme de traitement de donnees seion la reven- 
dication 6. dans lequel le gestionnaire de message- 
ries est con^u pour des communications entre des 
programmes de mise en file d'attente de messages 
sur un reseau heterogdne de systemes de traite- 
ment de donnees, le gestionnaire de messageries 
comprenant une interface de programmation d'ap- 
plication grkce k laquelle des applications se ratta- 
chent au gestionnaire de messageries et foumis- 
sant des services de mise en file d'attente permet- 
tant k des programmes d'application de placer des 
messages sur les files d'attente de messages en 
vue d'une recuperatbn asynchrone par d*autres 
programmes d'application. 



un programme emetteur d'un premier gestion- 
naire de messageries emettant un ou plusieurs 
messages k t'interieur d'une premiere unite de 
tSche commandee par un gestionnaire de point ^ 
de synchronisation. 

un programme recepteur dans un second ges- 
tionnaire de messageries recevant iesdits mes- 
sages k I'interieur d'une seconde unite de tdche 
commandee par un gestionnaire de point de 
synchronisation, 

les operations d'emission et de reception etant 
maintenues dans rincertitude, c'est-&-dire non so 
engagees, jusqu'^ la resolution des premiere 
et seconde unites de tdche. respectivement. et 

caracterise en ce que les premiere et seconde uni- 
tes de tSche sont liees logiquement de fa^on k ce ss 
que I'engagement du traitement k la resolution des 
premiere et seconde unites de tdche comprend soit 
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